UI: Fix slow pending Dag run checks on large databases - #75674

The dashboard polls for running or queued Dag runs to decide whether to auto-refresh, every 3 seconds while runs are active. The check fetched one Dag run ordered by id. When the statistics from the last ANALYZE count some pending runs, Postgres serves that by scanning dag_run by primary key from the oldest run, and since pending runs are the newest it reads nearly the whole table. Only the count is used, so the check now asks for no rows and reads total_entries.

Measured on Postgres with 5M finished runs, through the real endpoint.

The new test serves the endpoint from an msw handler that returns only limit rows with the full count in total_entries, as the API does. It checks that refresh still turns on and that every request asks for limit=0, and it fails on main.

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  • Claude Code (Opus 5.5)

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.